Developer CD Series 1993…ch: Other People's Memory/ADC Developer CD (1993-03) (''Other People's Memory'')_iso/Dev.CD Mar 93.iso/Development Platforms/CSMP Digests/csmp-v1-026.txt

Text File | 1992-11-18 | 42.8 KB | 1,124 lines | [TEXT/MPS ]

C.S.M.P. Digest             Sat, 21 Mar 92       Volume 1 : Issue 26

Today's Topics:

    HELP: hum noise when Mac is connected to an AMP
    System 7's pop-up CDEF - more lies (documentation errors)
    Another note regarding 'odoc' conversion to "puppet strings"
    implementing preference files


The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

These digests are available (by using FTP, account anonymous, your email
address as password) in the pub/mac/csmp-digest directory on ftp.cs.uoregon.
edu (try skinner.cs.uoregon.edu if that doesn't work).  This is also the home
of the comp.sys.mac.programmer Frequently Asked Questions list.

These digests are also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new digest as it is created.

The articles in these digests are taken directly from comp.sys.mac.programmer.
They are not edited; all articles included in this digest are in their original
posted form.  The only articles that are -not- included in these digests are
those which didn't receive any replies (except those that give information
rather than ask a question).  All replies to each article are concatenated
onto the original article in the order in which they were received.  Article
threads are not added to the digests until the last article added to the
thread is at least one month old (this is to ensure that the thread is dead
before adding it to the digests).

Send administrative mail to [e-mail].

-------------------------------------------------------

From: [e-mail] (Ross H Leung)
Subject: HELP: hum noise when Mac is connected to an AMP
Date: 14 Feb 92 05:46:44 GMT
Organization: State University of New York at Stony Brook

I am hooking my Macintosh to an Amplifier and get a lot of noise even
when I'm not playing anything through the Macintosh sound port.  It
is an annoying hum interference.  It has something dealing with the
grounding signal?!?  If anyone could help me, I appreciate it!

Please send mail to:
RLEUNG @ ic.sunysb.edu

Ross Leung
Instructional Computing
University at Stony Brook, NY



- -------------------------

From: [e-mail] (Mark Hartman)
Subject:  HELP: hum noise when Mac is connected to an AMP
Date: 19 Feb 92 18:01:52 GMT
Organization: Organization?  Who's organized?

The following question should probably go on the FAQL:

In article <[e-mail]>,
[e-mail] (Ross H Leung) writes:
>
> I am hooking my Macintosh to an Amplifier and get a lot of noise even
> when I'm not playing anything through the Macintosh sound port.  It
> is an annoying hum interference.  It has something dealing with the
> grounding signal?!?  If anyone could help me, I appreciate it!
>
> Ross Leung

As you have surmised, Ross, you have a grounding problem.  The problem is
that different transformers supply different DC ground potentials, and you
have two there (one in the Mac and one in the amp).

The solution is to use a third transformer in the audio circuit which will
isolate the grounds from the Mac and amplifier.  Any stereo store should be
able to help you for something under $20.  Ask for an "isolation transformer";
if they look blank, tell them you want "the box that gets rid of the hum,";
if they still look blank, get someone else to help you.

Mark Hartman
[e-mail]



---------------------------

From: [e-mail] (Mike Engber)
Subject: System 7's pop-up CDEF - more lies (documentation errors)
Date: 14 Feb 92 14:25:23 GMT
Organization: The Institute for the Learning Sciences


IM VI p. 3-18

 - The System 7 pop-up CDEF says the if you set useWFont, then the menu
   will appear in the current font and size. It does use the current
   font, but not the current size. The title and current item do use the
   current size.

 - To double check, I looked at a ComToolBox app (uATerm) and sure enough,
   those Geneva 9 pop-ups, pop into Geveva 12 menus.

 - Also, the standard MDEF only uses the system font and there is only one
   MDEF in the System 7 system file.

So how do they do it?

 - My guess is what's going on is that it briefly changes two global
   vars, SysFontFam and SysFontSize, to trick the standard MDEF into
   using the font it wants.

 - I tried this out, and you have to change both vars to get it to work
   at all & for some reason, the setting of SysFontSize seems ignored (12
   is always used)

Comments anyone? How evil a technique is this?

 You see, I'm still on my quest for a CDEF that implements type in pop
 up menus as per IM VI. I got no response to my posting that pointed
 out that IM VI falsely claims the standard pop-up CDEF will "readily"
 do it.  So I'm writing my own.

 I'm almost done, the one thing to figure out is how to support support
 (or not) the useWFont var code. (and I know the real answer is to
 write my own MDEF - but I can always point to Apple and say "monkey
 see, monkey do."

 It's tempting to use this global var technique (size bug and all) rather
 than have to couple my CDEF with an MDEF.

 I'll make the CDEF avail when it's done.

 Please cc via email if possible.

-ME



- -------------------------

From: [e-mail] (Pete Resnick)
Subject:  System 7's pop-up CDEF - more lies (documentation errors)
Date: 14 Feb 92 19:26:51 GMT
Organization: University of Illinois at Urbana

[e-mail] (Mike Engber) writes:

>So how do they do it?

> - My guess is what's going on is that it briefly changes two global
>   vars, SysFontFam and SysFontSize, to trick the standard MDEF into
>   using the font it wants.

> - I tried this out, and you have to change both vars to get it to work
>   at all & for some reason, the setting of SysFontSize seems ignored (12
>   is always used)

>Comments anyone? How evil a technique is this?

That is exactly what Apple does (along with changing 1 or two other
low-memory globals), and it does *usually* work as documented.
Unfortunately, some programs, especially MacWrite II, screw this up and
cause the point size to be ignored. I have reported this bug to Claris.
My guess is that it has something to do with installing their special
MDEF for the fancy font menu.

It's still a kludge, but I use it myself.

pr
--
Pete Resnick             (...so what is a mojo, and why would one be rising?)
Graduate assistant - Philosophy Department, Gregory Hall, UIUC
System manager - Cognitive Science Group, Beckman Institute, UIUC
Internet: [e-mail]



- -------------------------

From: [e-mail] (John Wallace)
Subject:  System 7's pop-up CDEF - more lies (documentation errors)
Date: 15 Feb 92 03:34:38 GMT
Organization: TRW Data Systems Center, Redondo Beach, CA

In article <[e-mail]> [e-mail] (Mike Engber) writes:
>
>So how do they do it [change the font of popup menus --JW]?
>
> - My guess is what's going on is that it briefly changes two global
>   vars, SysFontFam and SysFontSize, to trick the standard MDEF into
>   using the font it wants.
>
> - I tried this out, and you have to change both vars to get it to work
>   at all & for some reason, the setting of SysFontSize seems ignored (12
>   is always used)
>
>Comments anyone? How evil a technique is this?
>

This one drove me crazy.  But I finally got it.  You have to do three
things:

1. Set SysFontFam and SysFontSize to the appropriate values
   (even though it ignores the font size)

2. Set the window manager's font to the appropriate values since
   the menu appears to be actually drawn in the window manager's
   font,

3. Set lastSpExtra to -1 so that the low memory font globals
   are reloaded.

This should draw the menu in the desired font (if I remember
correctly, my source code is at my other office).  I didn't test to
see if I could do less such as just change SysFontFam and the window
manager's font size, for example.

Hope this helps!
John

- -
John Wallace        [e-mail]



- -------------------------

From: [e-mail] (David Phillip Oster)
Subject:  System 7's pop-up CDEF - more lies (documentation errors)
Date: 17 Feb 92 05:52:42 GMT
Organization: Whole Earth 'Lectronic Link, Sausalito, CA

I've used System 7's pop-up CDEF with useWFont, and it works exactly as
documented, i.e., it works, provided i run it from a fairly fresh boot.
If I run numerous other programs, something, I don't know what, mutates
the system so my Geneva 9 menus still have Geneva 9 titles, but the
menus themselves are drawn in Geneva 12.
--
-- David Phillip Oster - At least the government doesn't make death worse.
-- [e-mail] = {backbone}!well!oster



- -------------------------

From: [e-mail]
Subject:  System 7's pop-up CDEF - more lies (documentation errors)
Date: 17 Feb 92 21:19:26 GMT
Organization: Campus Computing Sites, University of Michigan-Ann Arbor

In article <[e-mail]> [e-mail] (Mike Engber) writes:
>
>IM VI p. 3-18
>
> - The System 7 pop-up CDEF says the if you set useWFont, then the menu
>   will appear in the current font and size. It does use the current
>   font, but not the current size. The title and current item do use the
>   current size.
>
> - To double check, I looked at a ComToolBox app (uATerm) and sure enough,
>   those Geneva 9 pop-ups, pop into Geveva 12 menus.
>
    I bet that you were running Microsoft Word, weren't you?!?  I've
got my own CDEF which does also does the font/size stuff (and more!) and
discovered that if MSWord (4.0, at least) is running the size change does
NOT take effect.

>So how do they do it?
>
> - My guess is what's going on is that it briefly changes two global
>   vars, SysFontFam and SysFontSize, to trick the standard MDEF into
>   using the font it wants.
>
    It actually mukcs about with a couple other LMGlobals in addition
to FontFam and FontSize, in order to invalidate the Font Mngr's caches.  Mine
does the same thing and you can see what the System's CDEF  does by doing a
ResEdit Disasm on the DEF and looking at on e of the last routines in the
code.

>Comments anyone? How evil a technique is this?
>
    I do the same thing that System does - if they can do it, so can I!

> You see, I'm still on my quest for a CDEF that implements type in pop
> up menus as per IM VI. I got no response to my posting that pointed
> out that IM VI falsely claims the standard pop-up CDEF will "readily"
> do it.  So I'm writing my own.
>
    That's what you've got to do - it's what I did!

> I'm almost done, the one thing to figure out is how to support support
> (or not) the useWFont var code. (and I know the real answer is to
> write my own MDEF - but I can always point to Apple and say "monkey
> see, monkey do."
>
    Here is the code that I use to "muck" with the appropriate LMG's
to get teh font'size correct in my pops.  This should probably get put
into the UMPG (Matt??).

void ChangeSystemFont(short fontNum, short fontSize)
{

    if((SysFontFam == fontNum) && (SysFontSize == fontSize))
    { /* don't make the system reload the font info unless it has to */
        return;
    }

    SysFontFam = fontNum;
    SysFontSize = fontSize;
    if (CurFMInput == 0)
        CurFMInput = -1L;
}

--
- ---------------------------------------------------------------------
Leonard Rosenthol          Internet: [e-mail]
Director of Advanced Technology   AppleLink: MACgician
Aladdin Systems, inc.          GEnie:     MACgician



---------------------------

From: [e-mail] (Jonathan Greenfield)
Subject: Another note regarding 'odoc' conversion to "puppet strings"
Date: 15 Feb 92 15:08:29 GMT
Organization: CIS Dept., Syracuse University

Background: In previous posts, it was suggested that the need to await
a reply (using the kAEWaitReply option) when posting 'odoc' events (for
conversion to "puppet strings") was a normal function of the posting
mechanism.  It was suggested that specifying the kAEWaitReply option
was merely equivalent to allowing the AE to be posted by calling
WaitNextEvent.

I responded that I could not accept that explanation, since it was not
true for AE's in general, and not even for 'odoc' events (as long as no
"puppet string" conversion is necessary).

After doing a few tests, I would like to add that the kAEQueueReply option
does not work with "puppet string" conversion, and that specifying
kAENoReply, but immediately following the AESend command with a WNE
call also does *not* work.

So I think it's clear that the need to wait for a reply *is* related to
the Process Manager's "puppet string" conversion, and *not* to the
Event Manager's normal AE posting mechanism.
--
J. S. Greenfield                                         [e-mail]
(I like to put 'greeny' here,
but my d*mn system wants a
*real* name!)                        "What's the difference between an orange?"



- -------------------------

From: [e-mail] (Grobbins)
Subject:  Another note regarding 'odoc' conversion to "puppet strings"
Date: 16 Feb 92 23:26:09 GMT
Organization: CTS, DTS, ETC

In article <[e-mail]> [e-mail] writes:
>It was suggested that specifying the kAEWaitReply option was
>merely equivalent to allowing the AE to be posted by calling WaitNextEvent.
>I responded that I could not accept that explanation, since it was not
>true for AE's in general, and not even for 'odoc' events (as long as no
>"puppet string" conversion is necessary).

No, it _is_ true that events don't get sent until WaitNextEvent time.
The exception is events sent by an application to itself.  This is
easy to demonstrate; just call AESend and then immediately enter an
infinite loop.

>After doing a few tests, I would like to add that the kAEQueueReply option
>does not work with "puppet string" conversion, and that specifying
>kAENoReply, but immediately following the AESend command with a WNE
>call also does *not* work.
>So I think it's clear that the need to wait for a reply *is* related to
>the Process Manager's "puppet string" conversion, and *not* to the
>Event Manager's normal AE posting mechanism.

I might believe you if the code below which I just wrote to test this
didn't work, but it does, so sorry, greeny.  The salient line is

  retCode := AESend(theAppleEvent, replyAppleEvent, kAENoReply,
                    kAENormalPriority, kAEDefaultTimeout, NIL, NIL);

There are some subtle points involved in sending odoc's which will be
coerced to puppet strings.  For example, the target app will have to be
made the current application for the operation to succeed, so the sending
app must accept its deactivate event and allow the immediate switch-out.
Also, in my tests, the target has to be identified by PSN rather than by
signature, though I don't know the why of that.

Replies are really nothing to get hung up over.

Grobbins               [e-mail]

Usual disclaimers apply.

- -


 PROCEDURE OpenDoc (itemFSSpecPtr: FSSpecPtr);
  LABEL 1;  { exception destination }
  CONST kTargetSignature = 'NISI'; { a System 6 application }
  VAR
   retCode: OSErr;
   theAppleEvent, replyAppleEvent: AppleEvent;
   odocAliasDescList, targetAddrDesc: AEDesc;
   fileAliasHandle: AliasHandle;
   tempStr: Str255;
   tempPSN, targetPSN: ProcessSerialNumber;
   tempPIR: ProcessInfoRec;
   myEventRecord: EventRecord;
   eventFlag: Boolean;
   i: Integer;
 BEGIN
  fileAliasHandle := NIL;
  targetAddrDesc.dataHandle := NIL;
  theAppleEvent.dataHandle := NIL;

  tempPSN.highLongOfPSN := 0;
  tempPSN.lowLongOfPSN := kNoProcess;
  targetPSN := tempPSN;

  tempPIR.processInfoLength := SizeOf(ProcessInfoRec);
  tempPIR.processName := @tempStr;
  tempPIR.processAppSpec := NIL;

  { target the application }
  WHILE GetNextProcess(tempPSN) = noErr DO
    IF GetProcessInformation(tempPSN, tempPIR) = noErr THEN
     IF tempPIR.processSignature = kTargetSignature THEN
      targetPSN := tempPSN;

  IF targetPSN.lowLongOfPSN = kNoProcess THEN GOTO 1;

  retCode := AECreateDesc(typeProcessSerialNumber, @targetPSN, SizeOf(targetPSN), targetAddrDesc);
  IF retCode <> noErr THEN GOTO 1;

  { create the event }
  retCode := AECreateAppleEvent(kCoreEventClass, kAEOpenDocuments, targetAddrDesc, kAutoGenerateReturnID, kAnyTransactionID, theAppleEvent);
  IF retCode <> noErr THEN GOTO 1;

  { create a list containing an alias to a file }
  retCode := NewAlias(NIL, itemFSSpecPtr^, fileAliasHandle);
  IF retCode <> noErr THEN GOTO 1;

  retCode := AECreateList(NIL, 0, false, odocAliasDescList);
  IF retCode <> noErr THEN GOTO 1;

  HLock(Handle(fileAliasHandle));
  retCode := AEPutPtr(odocAliasDescList, 1, typeAlias, Pointer(fileAliasHandle^), fileAliasHandle^^.aliasSize);
  IF retCode <> noErr THEN GOTO 1;
  HUnlock(Handle(fileAliasHandle));

  { make the list the direct object of the apple event and send it }
  retCode := AEPutParamDesc(theAppleEvent, keyDirectObject, odocAliasDescList);
  IF retCode <> noErr THEN GOTO 1;

  retCode := AESend(theAppleEvent, replyAppleEvent, kAENoReply, kAENormalPriority, kAEDefaultTimeout, NIL, NIL);
  IF retCode <> noErr THEN GOTO 1;

  SysBeep(10);
  eventFlag := WaitNextEvent(everyEvent, myEventRecord, 30, NIL);
  eventFlag := WaitNextEvent(everyEvent, myEventRecord, 30, NIL);
  eventFlag := WaitNextEvent(everyEvent, myEventRecord, 30, NIL);
  SysBeep(10);

1:
  IF retCode <> noErr THEN
   BEGIN
    NumToString(retCode, tempStr);
    DebugStr(Concat('Error:', tempStr));
   END;
  IF targetAddrDesc.dataHandle <> NIL THEN
   retCode := AEDisposeDesc(targetAddrDesc);
  IF odocAliasDescList.dataHandle <> NIL THEN
   retCode := AEDisposeDesc(odocAliasDescList);
  IF theAppleEvent.dataHandle <> NIL THEN
   retCode := AEDisposeDesc(theAppleEvent);
  IF fileAliasHandle <> NIL THEN
   DisposHandle(Handle(fileAliasHandle));
 END;




- -------------------------

From: [e-mail] (Jonathan Greenfield)
Subject:  Another note regarding 'odoc' conversion to "puppet strings"
Organization: CIS Dept., Syracuse University
Date: Mon, 17 Feb 92 10:08:16 EST

In article <[e-mail]> [e-mail] (Grobbins) writes:
>>It was suggested that specifying the kAEWaitReply option was
>>merely equivalent to allowing the AE to be posted by calling WaitNextEvent.
>>I responded that I could not accept that explanation, since it was not
>>true for AE's in general, and not even for 'odoc' events (as long as no
>>"puppet string" conversion is necessary).
>
>No, it _is_ true that events don't get sent until WaitNextEvent time.
>The exception is events sent by an application to itself.  This is
>easy to demonstrate; just call AESend and then immediately enter an
>infinite loop.

Let's not play games--if you read my post you will see that I said nothing
to indicate that events got sent before WNE time.  What I said is that
the kAEWaitReply option DOES NOT SEEM TO BE EQUIVALENT TO a call to WNE,
as you suggested.  It is entirely possible that kAEWaitReply invokes a
call to WNE, but as I have indicated previously, it seems to do *more*
than just that.

>>After doing a few tests, I would like to add that the kAEQueueReply option
>>does not work with "puppet string" conversion, and that specifying
>>kAENoReply, but immediately following the AESend command with a WNE
>>call also does *not* work.
>>So I think it's clear that the need to wait for a reply *is* related to
>>the Process Manager's "puppet string" conversion, and *not* to the
>>Event Manager's normal AE posting mechanism.
>
>I might believe you if the code below which I just wrote to test this
>didn't work, but it does, so sorry, greeny.  The salient line is

You are really being obnoxious.  How about posting, "Well, I was able
to get puppet-string conversion without awaiting a reply in the
following *case*, so it doesn't seem that one *always* has to await a
reply."

How about trying to determine whether I have done something strange, that
might explain the behavior I describe?

But no, you feel obliged to presume that if it *happened* to work for
you in *one* case, then it must *always* work that way, even if some other
crazy (stupid? lying??) person has suggested otherwise.  Gee, I don't
work for Apple (and I certainly make no claim to be a Mac expert), so that
means that the information that present should simply be ignored.

>  retCode := AESend(theAppleEvent, replyAppleEvent, kAENoReply,
>                    kAENormalPriority, kAEDefaultTimeout, NIL, NIL);
>
>There are some subtle points involved in sending odoc's which will be
>coerced to puppet strings.

Really?!!  Gee, I thought that was the whole point of my posts, in the first
place.  To point out some peculiar (and apparently undocumented) behavior
when attempting to convert 'odoc' events to puppet-strings.

I am aware of one "snippet" that mentioned puppet-string conversion.  It
made the conversion sound as though it was completely transparent to the
application programmer.  This is not the case.  It would be nice to have
Apple provide some documentation that more clearly describes what is necessary
for puppet string conversion.  Next best is to exchange information among
ourselves, so that we can try to figure out what is happening, on our own.

Your original response suggested that the peculiar behavior was attributable
to sending apple events in general.  When I responded that such an explanation
did not fit the behavior that I observed, you write back, "Ho ho ho, there
are some subtle points involved..."

Very helpful.

>For example, the target app will have to be
>made the current application for the operation to succeed, so the sending
>app must accept its deactivate event and allow the immediate switch-out.
>Also, in my tests, the target has to be identified by PSN rather than by
>signature, though I don't know the why of that.

I do specify the target address by PSN.  And what does a call to WNE do,
if it doesn't give up the processor to allow another application to
become the current application.

So these ad-hoc suggestions do not convince me.

I even tried forcing the target app into the foreground before sending
the event.  Strangely enough, the puppet-string conversion didn't work
then, even when the kAEWaitReply option was specified!

Now why should an app being in the foreground *prevent* the puppet
string conversion from occurring.  (It doesn't prevent events from
being sent, in general--that is, HLE-aware apps can get a normal 'odoc'
without trouble, while they are in the foreground.)  That's pretty strange
behavior, in my book.

>Replies are really nothing to get hung up over.

If you are just guessing as to what works, and what doesn't, then why
don't you just contribute your observations in a constructive manner,
rather than suggesting, in a know-it-all Mac-programming-net-god tone,
that your observations are the gospel truth.

It seems pretty clear to me that your knowledge of these matters is
limited to your own ad hoc observations.

There's nothing wrong with that--but don't try to mislead the rest of
us by pretending to have authoritative information.

And you certainly don't have to be rude and obnoxious.

- ------------------------

Here's the code segment that I use to create and send the 'odoc' event.
I'll be glad if someone would like to constructively point out some problem
in the process.  I have no interest in hearing from individuals who are
interested in summarily dismissing my observations without taking any time
to understand the matter.


err := AECreateDesc(typeProcessSerialNumber, @applPSN, Sizeof(applPSN),
                    applAddress);
err := AECreateAppleEvent(kCoreEventClass, kAEOpenDocuments, applAddress,
                          kAutoGenerateReturnID, kAnyTransactionID,
                          theAppleEvent);
err := AEPutParamDesc(theAppleEvent, keyDirectObject, docList);
err := AESend(theAppleEvent, dummyReply, kAEWaitReply + kAECanInteract +
              kAECanSwitchLayer, kAEHighPriority, 30, nil, nil);


This code segment works fine for both AE-aware and non-AE-aware apps.
Change the kAEWaitReply to kAENoReply (and follow the segment with a
call to WNE), however, and the segment will only work for AE-aware apps.
(In other words, the puppet string conversion won't work.)

(Note: the timeout is set to 30, simply because some applications do
not generate a reply--therefore hanging my application until the timeout
is reached.  I have found that 30 ticks is sufficient for apps to
receive the 'odoc' event.  In any case, all of my tests were originally
performed with the kAEDefaultTimeout constant specified.)

So any thoughts?  (from people who are interested in finding out how
puppet-string conversion works--not from people who are simply interested
in touting their own imagined abilities as a mac.guru)
--
J. S. Greenfield                                         [e-mail]
(I like to put 'greeny' here,
but my d*mn system wants a
*real* name!)                        "What's the difference between an orange?"



- -------------------------

From: [e-mail] (Kent Sandvik)
Subject:  Another note regarding 'odoc' conversion to "puppet strings"
Date: 20 Feb 92 05:26:12 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Jonathan Greenfield) writes:
> In article <[e-mail]> [e-mail] (Grobbins) writes:
> Really?!!  Gee, I thought that was the whole point of my posts, in the first
> place.  To point out some peculiar (and apparently undocumented) behavior
> when attempting to convert 'odoc' events to puppet-strings.
>
> I am aware of one "snippet" that mentioned puppet-string conversion.  It
> made the conversion sound as though it was completely transparent to the
> application programmer.  This is not the case.  It would be nice to have
> Apple provide some documentation that more clearly describes what is necessary
> for puppet string conversion.  Next best is to exchange information among
> ourselves, so that we can try to figure out what is happening, on our own.

I'm no expert with AEs, no way. However I would like to point out that
sometimes we don't provide information in the best interest of the developer
community. Usually we don't want to document issues which are hacky,
dirty, and most likely subject to change.

If as you say "we can try to figure out what is happening, on our own"
is the preferred way, you must realize the dangers with trying to use
undocumented and skanky issues which might break the code in the long run.

This is the reason mythological things such as MF 'puppet strings', the
infamous Layer Manager, and many other things are not considered to be
documented. We are not trying to make life hard for the developers, quite
the opposite! It's hard to explain this thing, but I think each one knows
the intent behind this 'secrecy'. It's not that we would like to keep all
the secrets for our own internal hacking use. In general any Macintosh
program which *will work* for the end user is a good thing. Note that
I stressed "will work".

Then if certain features are not available, it is the job of DTS to at least
find workarounds, and that's one of our missions.

Finally, I don't know, maybe I'm getting old, but I don't consider official
flaming to be very constructive in programmer newsgroups. I think Greg is
doing a fine job over here, and as many of you have seen he's helping developers
in this newsgroup - an activity which is beyond his job responsibilities, and
he could as well work overtime with internal projects...

If we start flaming each other, it just leads to a situation where someone who
provides free support will stop doing it, and that's not a good thing for anyone.

If anyone wants to flame me, please send an email to [e-mail] before
this Friday afternoon, then this boy is heading off to sunny Florida!

Kent Sandvik
not speaking for DTS / Dynamic Languge Evangelist



---------------------------

From: [e-mail] (Ronald P. Smith)
Subject: implementing preference files
Organization: University of Illinois at Urbana
Date: Mon, 17 Feb 1992 05:40:04 GMT

I am working on a piece of software which will be distributed on
CD-ROM.  I have to save information as to the user's preferences
somewhere.  I normally would save this on the application's rescources,
but since this will be on CD-ROM, I can't.  I am having problems
implementing a preference file.  I want to be able to have a preferences
file somewhere, and have my program look in the most likely places for it
 (root, system folder, current dir), and if not found.. go looking for it.

I was wondering what most people do to handle preference files?

Do you allow the user to place the file anywhere, and go looking for
it using some search algorithm using param block based file routines
(I hope not!).  I suppose I could do this, but it seems there should
be a better way.. Any input would be greatly appreciated..

Ron Smith ([e-mail])



- -------------------------

From: [e-mail] (GILPIN, W.W.)
Subject:  implementing preference files
Date: 17 Feb 92 09:01:00 GMT
Organization: Texas A&M University, Academic Computing Services

>I was wondering what most people do to handle preference files?
>
>Do you allow the user to place the file anywhere, and go looking for
>it using some search algorithm using param block based file routines
>(I hope not!).  I suppose I could do this, but it seems there should
>be a better way.. Any input would be greatly appreciated..

Dear God NO! The standard way to implement preferences files is to put them
in a folder named Preferences in the System Folder. (Find the system folder
with SysEnvirons or Gestalt). That's the easiest way.

Wes Gilpin
[e-mail]
WWG2101@TAMZEUS



- -------------------------

From: [e-mail] (Karl-Koenig Koenigsson)
Subject:  implementing preference files
Date: 17 Feb 92 13:10:15 GMT
Organization: Dept. of Scientific Computing, Uppsala Univ.

[e-mail] (GILPIN, W.W.) writes:
: Dear God NO! The standard way to implement preferences files is to put them
: in a folder named Preferences in the System Folder. (Find the system folder
: with SysEnvirons or Gestalt). That's the easiest way.

Or better still: system 7 has a feature callde FindFolder (I believe)
which returns the IDs of predefined folders such as the preferences
folder, or the extenxion folder, etc.

The problem with running american software on a (in my case) swedish
mac, is that some software is not properly written, and I end up with
an extra folder inside my system folder.

Cheers

    koenig


--
Karl-Koenig Koenigsson, Computer consultant
[e-mail]                   "No matter wherever you go, there you are"



- -------------------------

From: [e-mail] (GILPIN, W.W)
Subject:  implementing preference files
Date: 18 Feb 92 01:07:00 GMT
Organization: Texas A&M University, Academic Computing Services

>[e-mail] (GILPIN, W.W.) writes:
>: Dear God NO! The standard way to implement preferences files is to put them
>: in a folder named Preferences in the System Folder. (Find the system folder
>: with SysEnvirons or Gestalt). That's the easiest way.
>
>Or better still: system 7 has a feature callde FindFolder (I believe)
>which returns the IDs of predefined folders such as the preferences
>folder, or the extenxion folder, etc.

This is indeed a System 7.0.x function that I overlooked. To use this you need
to determine if Gestalt is available, then use Gestalt to determine if
FindFolder is available. (CONST FindFolderPresent = 0;) Then pass Findfolder
the code 'pref'. This only works with 7.0, however. If you're using 6.0.x,
you can either do like Stuffit Deluxe did and use a Preferences folder in
the system folder, or you can do like just about every other 6.0.x program
does and just drop your pref's file in the system folder. The first method is
probably not too advisable. Just make sure that you take into account the
possibility of 6.0.x OR 7.0.x

>The problem with running american software on a (in my case) swedish
>mac, is that some software is not properly written, and I end up with
>an extra folder inside my system folder.

Got me there too. I have no excuse.

Wes Gilpin
WWG2101@TAMZEUS
[e-mail]



- -------------------------

From: [e-mail] (Jon W{tte)
Subject:  implementing preference files
Date: 18 Feb 92 09:05:05 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

> [e-mail] (GILPIN, W.W) writes:

   This is indeed a System 7.0.x function that I overlooked. To use this you need
   to determine if Gestalt is available, then use Gestalt to determine if
   FindFolder is available. (CONST FindFolderPresent = 0;) Then pass Findfolder

You don't have to check for _Gestalt, the Gestalt glue does that
automagically. Just call Gestalt, and you'll get an error result
code back if it's not there.

--
This Signature is distributed under the conditions of the Signature License,
available at a fee from   [e-mail]  (Jon W{tte)  Reading the Signature
implies that you accept to be bound by the terms in said License. Should you
not agree on any of these terms, you must return the Signature unread to me.



- -------------------------

From: [e-mail] (Christian Beijner)
Subject:  implementing preference files
Date: 18 Feb 92 09:33:36 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

In article <[e-mail]> [e-mail] (GILPIN, W.W.) writes:
>>I was wondering what most people do to handle preference files?
>>
>>Do you allow the user to place the file anywhere, and go looking for
>>it using some search algorithm using param block based file routines
>>(I hope not!).  I suppose I could do this, but it seems there should
>>be a better way.. Any input would be greatly appreciated..
>
>Dear God NO! The standard way to implement preferences files is to put them
>in a folder named Preferences in the System Folder. (Find the system folder
>with SysEnvirons or Gestalt). That's the easiest way.

Another way is using the curresfile (= your applicationfile before opening any
others) to find out where your application is (cant remember exact way)
and use the folder where the application is to store your prefs.
This has several advantages:
  1) Doesn't clog up the system folder
  2) If the user erases your program he probably erases the prefs file also,
     which isnt neccessarily so if it is somewhere in the system folder.
  3) Usable on system 6.x.x
/Chris



- -------------------------

From: [e-mail] (Matthias Ulrich Neeracher)
Subject:  implementing preference files
Date: 18 Feb 92 18:56:41 GMT
Organization: Integrated Systems Laboratory, ETH, Zurich

In article <[e-mail]> [e-mail] (GILPIN, W.W) writes:
>>[e-mail] (GILPIN, W.W.) writes:
>>: Dear God NO! The standard way to implement preferences files is to put them
>>: in a folder named Preferences in the System Folder. (Find the system folder
>>: with SysEnvirons or Gestalt). That's the easiest way.
>>
>>Or better still: system 7 has a feature callde FindFolder (I believe)
>>which returns the IDs of predefined folders such as the preferences
>>folder, or the extenxion folder, etc.
>
>This is indeed a System 7.0.x function that I overlooked. To use this you need
>to determine if Gestalt is available, then use Gestalt to determine if
>FindFolder is available. (CONST FindFolderPresent = 0;) Then pass Findfolder
>the code 'pref'. This only works with 7.0, however. If you're using 6.0.x,
>you can either do like Stuffit Deluxe did and use a Preferences folder in
>the system folder, or you can do like just about every other 6.0.x program
>does and just drop your pref's file in the system folder. The first method is
>probably not too advisable. Just make sure that you take into account the
>possibility of 6.0.x OR 7.0.x

Actually, MPW has glue for FindFolder which automatically returns the System
Folder if you ask for the Preferences folder under 6.0.x

Matthias

- ---
Matthias Neeracher                                   [e-mail]
 "You must have picked up that copy of Scarlett instead of Inside Mac
  when you tried to find the right call..." -- Keith Rollin



- -------------------------

From: [e-mail] (Christopher Tate)
Subject:  implementing preference files
Date: 18 Feb 92 13:14:17 GMT
Organization: Penn State University

In article <[e-mail]>, [e-mail] (Christian
Beijner) says:
>
>Another way is using the curresfile (= your applicationfile before opening any
>others) to find out where your application is (cant remember exact way)
>and use the folder where the application is to store your prefs.
>This has several advantages:
>  1) Doesn't clog up the system folder
>  2) If the user erases your program he probably erases the prefs file also,
>     which isnt neccessarily so if it is somewhere in the system folder.
>  3) Usable on system 6.x.x

Ack!  Don't do this!  It has the following additional feature:

   4) Causes your application to break when installed on a read-only
      file server.

Ready,Set,Go 4.5 insists on using its folder for temp files or some such,
and so LetraSet lost a *lot* of potential business from PSU -- we can't
use it in our labs, so we didn't buy it....

Also, if you go back and read the original poster's question, his main
problem is that his app will be distributed on CD-ROM -- another case
of simply not being able to write to the volume holding the app.  Yet
a third case is running off of a locked floppy (which many people prefer
to do these days, what with viruses floating about and such).

- -----
Christopher Tate     | Cryptogram #23:
[e-mail] |
[e-mail]  |   QNLF U MFLGX YR OIULFXD, CNLR CWIF CNLUI AGSMD.
- -------------------|
Send me the answer!  |



- -------------------------

From: [e-mail] (Jon W{tte)
Subject:  implementing preference files
Date: 18 Feb 92 16:05:12 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

.se> [e-mail] (Christian Beijner) writes:

   Another way is using the curresfile (= your applicationfile before opening any
   others) to find out where your application is (cant remember exact way)
   and use the folder where the application is to store your prefs.
   This has several advantages:
     1) Doesn't clog up the system folder
     2) If the user erases your program he probably erases the prefs file also,
    which isnt neccessarily so if it is somewhere in the system folder.
     3) Usable on system 6.x.x
   /Chris


It also has these DISadvantages:

    1) Fails miserably when stored on locked floppy
    2) Fails miserably when stored on CD ROM
    3) Fails miserably when stored on file server (so several
       users can launch it simultaneously)
    4) Fails miserably when users keep a lot of apps in one
       folder for easy access
    5) Fails miserably when ...

--
This Signature is distributed under the conditions of the Signature License,
available at a fee from   [e-mail]  (Jon W{tte)  Reading the Signature
implies that you accept to be bound by the terms in said License. Should you
not agree on any of these terms, you must return the Signature unread to me.



- -------------------------

From: [e-mail] (GILPIN, W.W.)
Subject:  implementing preference files
Date: 18 Feb 92 22:39:00 GMT
Organization: Texas A&M University, Academic Computing Services

>Another way is using the curresfile (= your applicationfile before opening any
>others) to find out where your application is (cant remember exact way)
>and use the folder where the application is to store your prefs.
>This has several advantages:

Disadvantage: You can't do this on a read-only disk. I think that was his
original question, hence the discussion.

Wes Gilpin
WWG2101@TAMZEUS



- -------------------------

From: [e-mail] (Heeren Pathak)
Subject:  implementing preference files
Organization: Mitre Corporation
Date: Wed, 19 Feb 1992 12:38:37 GMT

In article <[e-mail]>, [e-mail] (Christian Beijner) writes:
>
>
> Another way is using the curresfile (= your applicationfile before opening any
> others) to find out where your application is (cant remember exact way)
> and use the folder where the application is to store your prefs.
> This has several advantages:
>   1) Doesn't clog up the system folder
>   2) If the user erases your program he probably erases the prefs file also,
>      which isnt neccessarily so if it is somewhere in the system folder.
>   3) Usable on system 6.x.x
> /Chris
>

The only problem with this is that it fails horribly if the user is
running the application off of a file server and they only have read
access.

--Heeren



- -------------------------

From: [e-mail] (Karl-Koenig Koenigsson)
Subject:  implementing preference files
Date: 20 Feb 92 00:19:53 GMT
Organization: Dept. of Scientific Computing, Uppsala Univ., Sweden

In article <[e-mail]> I wrote:
>The problem with running american software on a (in my case) swedish
>mac, is that some software is not properly written, and I end up with
>an extra folder inside my system folder.

I got some response to what I considered "properly written" and
thought I should clarify this a bit:

The problem with implementing a "Preferences" folder is that you are
on your own -- that is not a good idea.

What I think are good manners in a non system 7 environment are (in order
of preference):

-    Let the user choose a folder were to store the pref file (and
    maybe even name it) and    save the FileID in the application (*)
-    Save the prefs in the application (*)
-    Store the prefs as a file in the system folder (**)

The problem with (*) is that if you run you application from a read
only medium, you will run into trouble, and the problem with (**) is
that you will clutter your system folder.

The name of the system folder has always been translated and system
versions before 7.0 were designed to keep things in the system folder
(consider PostScript fonts for downloading to a printer or
INITS/cdevs).  Although this solution was not a nice one it was a
consistent way of doing things, and most applications conformed to
this standard.

I am maybe more grumpy than most people regarding this issue. The
problem is that being in a profession where all the new terminology
and all the new concepts are coming from the English language, you
find your own being slowly replaced. The Swedish computer
professionals of today are making their own language, merging Swedish
suffices with English words, creating a hideous mess...

This makes the problem of getting "ordinary people" to accept
computers a difficult one. They tend to look on those who work with
computers with awe, suspicion and fear, since they deal with machines,
and speak a language, noone understands. It is therefore a very
important task to make the language of computers an understandable
one.

So, to conclude: If you want to make your applications runable from
read only media, keep the prefs in the system folder. Otherwise let
the user choose. The only exception would be if you keep a lot of
files, like Aldus or Claris, where a dedicated folder with the
name of the program or the company is acceptable.

Cheers

    koenig




--
Karl-Koenig Koenigsson, Computer consultant
[e-mail]                   "No matter wherever you go, there you are"



---------------------------

End of C.S.M.P. Digest
**********************